Some types of communications in packet-based networks demand very small latencies in end-to-end transmission time. For some applications, even delays on the order of milliseconds can adversely affect a desired outcome, such as buying or selling a security at a target price. Conventional “store-and-forward” techniques, however, introduce additional latency because the network devices implementing the techniques (e.g., bridge devices) must wait to receive and buffer an entire packet before beginning to forward the packet to a next device. For large packets, this delay can be significant.
One known technique that generally helps to reduce latency is referred to as “cut-through.” With cut-through, a network device processes a portion (e.g., a header) of a packet, and begins to forward/transmit the packet to a next device, before the entire packet has been received and written to memory. While cut-through generally reduces latency, conventional cut-through techniques nonetheless suffer from various drawbacks. One such drawback arises because Ethernet protocols generally require a single packet to be transmitted between network devices in a continuous fashion, with breaks or pauses creating an error condition. This can be problematic, for example, when the network device receives a packet on a relatively slow ingress port and forwards the packet to a relatively fast egress port. Because some of the packet that ingresses at a relatively slow port is not yet available in memory when the egress port begins to retrieve the packet data for forwarding/transmission, the egress port may eventually run out of packet data to be transmitted before transmission of the entire packet has been completed. This scenario is generally referred to as “under-run.”
Another drawback of conventional cut-through stems from the fact that forwarding is started before the full packet can be processed, and thus certain types of information that may be needed or useful for various, typically non-forwarding, operations are not yet known when the packet is transmitted. For example, a byte count of a received packet, which may be useful for metering and various other operations, may not be known at the time cut-through forwarding begins. As another example, knowledge of whether the received packet is error-free, which may be useful for mirroring and various other operations, may not be known at the time cut-through forwarding begins.